<p>Disclosure of version information, usually overlooked by developers but disclosed by default by the systems and frameworks in use, can pose a
significant security risk depending on the production environement.</p>
<p>Once this information is public, attackers can use it to identify potential security holes or vulnerabilities specific to that version.</p>
<p>Furthermore, if the published version information indicates the use of outdated or unsupported software, it becomes easier for attackers to exploit
known vulnerabilities. They can search for published vulnerabilities related to that version and launch attacks that specifically target those
vulnerabilities.</p>
<h2>Ask Yourself Whether</h2>
<ul>
  <li> Version information is accessible to end users. </li>
  <li> Internal systems do not benefit from timely patch management workflows. </li>
</ul>
<p>There is a risk if you answered yes to any of these questions.</p>
<h2>Recommended Secure Coding Practices</h2>
<p>In general, it is recommended to keep internal technical information within internal systems to control what attackers know about the underlying
architectures. This is known as the "need to know" principle.</p>
<p>The most effective solution is to remove version information disclosure from what end users can see, such as the "x-powered-by" header.<br> This
can be achieved directly through the web application code, server (nginx, apache) or firewalls.</p>
<p>Disabling the server signature provides additional protection by reducing the amount of information available to attackers. Note, however, that
this does not provide as much protection as regular updates and patches.<br> Security by obscurity is the least foolproof solution of all. It should
never be the only defense mechanism and should always be combined with other security measures.</p>
<h2>Sensitive Code Example</h2>
<pre>
@GetMapping(value = "/example")
public ResponseEntity&lt;String&gt; example() {
  HttpHeaders responseHeaders = new HttpHeaders();
  responseHeaders.set("x-powered-by", "myproduct"); // Sensitive

  return new ResponseEntity&lt;String&gt;(
      "example",
      responseHeaders,
      HttpStatus.CREATED);
}
</pre>
<h2>Compliant Solution</h2>
<p>Do not disclose version information unless necessary. The <code>x-powered-by</code> or <code>Server</code> HTTP headers should not be used.</p>
<h2>See</h2>
<ul>
  <li> OWASP - <a href="https://owasp.org/Top10/A05_2021-Security_Misconfiguration/">Top 10 2021 Category A5 - Security Misconfiguration</a> </li>
  <li> <a
  href="https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/01-Information_Gathering/08-Fingerprint_Web_Application_Framework.html">OWASP Testing Guide - OTG-INFO-008</a> - Fingerprint Web Application Framework </li>
  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">Top 10 2017 Category A6 - Security
  Misconfiguration</a> </li>
  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/200">CWE-200 - Information Exposure</a> </li>
</ul>

